In the past, there have been three major application architectures that have been used to build and deploy software that supports end-user processes. This is in contrast to lower level software that supports hardware and software processes such as operating systems. These three architectures have closely mirrored the evolution of the hardware environment. First, in the beginning of the computer age, hardware was centralized, expensive and very tightly controlled. This was typified by the mainframe computer with optional dedicated terminals to support end users. A monolithic or host-based application architecture evolved to build software in the mainframe environment, with virtually all computer tasks managed by the central mainframe computer. This application architecture was simple to manage as it was all in one place, but had shortcomings in its ability to support complex processes and in its ability to grow and expand to support larger user populations.
Second, with the advent of the networked personal computer (PC), the ability to use a PC to render graphic images and Windows® spawned a new application architecture called client-server computing. The key feature of this architecture was the delegation of some portion of the application computer tasks to the client computer. The distribution of tasks between the client and the server was based on their technical nature, with presentation/graphic tasks sent to the client, database tasks delegated to the central server, and application logic existing in either place or on a middle tier called the application server. Client-server computing was a huge improvement over past architectures in that it supported more complex processes with more intuitive interfaces and was better able to grow to support large user populations by distributing the processing and communications activities load across many computers.
Third, with the broad adoption of the Internet, a new style of application architecture emerged called n-Tier (or sometimes “thin-client”) that was expressly designed to take advantage of browsers, Internet servers, and Internet standards. Thin-client applications are designed to be small, so that the data processing is performed predominantly on the server, rather than on the client. N-Tier application architecture refers to applications that are broken into different layers or tiers, where modifications to the application may be made by altering or replacing a particular tier, rather than by replacing the entire application. The n-Tier architecture is similar to client-server computing in that computer tasks are distributed between a central server complex of computers and a client computer (typically a PC). It is different in that much of the work that the client computer performed in the client-server model is migrated back to the server. Clients are left with only a portion of the presentation logic, which runs inside of a browser or similar presentation program. This architecture had two important improvements over client-server computing. It requires no installed software at the client layer, which cuts application management costs dramatically, and it allows ubiquitous access to applications. Users may now access their software from wherever the Internet takes them. The trade-off for these improvements is that in re-centralizing the computer tasks, this architecture is much slower than a traditional client-server model, and it provides weaker security and a less intuitive user interface. The result is that n-Tier applications are sufficient for simple, non-mission critical applications, but are unworkable for many of the most important software needs in today's economy. Prior attempts to overcome these challenges have fallen short in suitably addressing both concerns simultaneously. That is, there is a lack of a suitable architecture that may centralize applications while simultaneously providing an agile response, sufficient security, and an intuitive user interface.
For example, U.S. Pat. Nos. 5,924,094 and 6,446,092 appear to disclose independent distributed database systems where all nodes are peers, and no node acts as a server for the others. The systems do not distinguish between master and slave sites since each site stores all and only the data required to work off-line with local data. All application transactions are made against the local database. Sites sharing the same data synchronize their changes periodically in the background. In these systems, there are no on-line or distributed application transactions because all application transactions are local. Users employ local databases to gain performance speed. However, the '094 and '092 patents fail to disclose means by which application programs may be distributed to client devices to enable sufficient autonomy and computing capability to complete entire business transactions while simultaneously providing a secure means with which to conduct the transactions.
Additionally, U.S. Pat. Nos. 6,049,664 and 6,272,673 appear to disclose a mechanism for creating a software application for execution on a network that has multiple tiers. The mechanism includes means for specifying application components, which allows an application component to be assigned to execute on any of the tiers of the network. The mechanism also includes means for associating the application components with a hypertext page. The components are then executed in response to requests for the hypertext page. The '664 patent and the '673 patent, however, fail to disclose means with which to suitably distribute applications based upon the boundaries of a required transaction. Instead, the '664 patent and the '673 patent perform a conventional thin client distribution assignment to a client based upon the type of task being performed.
U.S. Pat. No. 6,636,900 is another example of executing distributed objects over a network. The '900 patent develops an application using object oriented code to utilize objects that are self contained application components. Each object of the application is distributed over a network. An application process may request an application object from a local or a remote network location using the address of the object, the name of the object, and any input values. If the requested object is not on the local computer, the computer on which the requested object resides receives the name of the object, executes the object using the input values, generates an output value of the object, and sends the output value to the requesting computer. The output value is then used in the running application. Thus, the object execution is remote, and the user of the requesting computer is given no indication of this remote operation. While the '900 patent employs a distributed environment, it fails to disclose means for distributed applications that are transferred to the client devices, executed, and then removed. The apparatus and method of the '900 patent provides load balancing of the application components over the network, but fails to disclose means for receiving executable applications on remote or periodically connected devices.
None of the previous architectures adequately provide the ubiquity of n-Tier applications together with the usability and sophistication of a client-server system. What is needed is a new type of architecture that distributes centralized applications while simultaneously providing agile client-side responses, sufficient security, and an intuitive user interface.